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Introduzione 

Da almeno tre anni i mashup sono diventati un argomento dibattuto 
e una tecnologia largamente adottata nel panorama informativo: 
in quanto applicazioni situazionali (devo questa efficace definizione 
a ReadWrifeWeb^) proliferano in im ambifo, come è ormai il Web 
2.0 (l'eficheffa è di comodo), ricco di confenufi, relazioni, scambi, 
collaborazioni. Il remix che il mashup si propone di attuare non 
è solo da infendere come semplice giusfapposizione di confenufi 
ma come vera e propria (ri)combinazione di dafi, anche aH'inferno 
di confesfi differenfi: ne sono un esempio quelle applicazioni che 
fondono in un unico flusso, informazioni provenienti dal Web e da 
programmi deskfop come i clienf e-mail o le infranef aziendali. 

Le bibliofeche, sforicamenfe piuffosfo caule di Ironie a miscele 
pofenzialmenfe caotiche di informazioni provenienfi da fonfi di¬ 
verse, si sono lanciale con convinzione nell'esplorazione di quesfa 
nuova fendenza. È sempre isfruffivo consulfare a proposito il social 
nefwork Mashed Library,^ che dà confo di luffe le iniziative su que- 

^http://www.readwriteweb.com/archives/proto_desktop_mashups.php. 
^http://mashedlibrary.ning.com/. 
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sto tema che si susseguono in Gran Bretagna dal 2008. Inoltre, la 
recente tendenza di alcune grandi biblioteche, ad "aprire" i propri 
cataloghi, rendendo disponibili per il riutilizzo i dati bibliografici (il 
tesoro nascosto delle biblioteche!), testimonia deH'interesse a creare 
nuove modalità di utilizzo delle informazioni e della tendenza a una 
loro sempre maggiore integrazione, a un loro sempre più creativo 
arricchimento. 

Di seguito potete leggere la versione italiana del capitolo "Li¬ 
brary mashups: Behind thè scenes", pubblicato nel volume Library 
Mashups: Exploring New Ways to Deliver Library Data, edito da Infor¬ 
mation Today nel 2009.^ Il capitolo in inglese è disponibile in accesso 
aperto anche sul repository dell'Università di Milano-Bicocca^. Invito 
a leggere il libro non solo per tuffarsi nel mare di informazioni ed 
esempi prafici che propone, ma anche, perché no, per sostenere un 
editore che acconsente alla ripubblicazione sul Web dei contenu¬ 
ti dei suoi libri, abbracciando una sfida, quella delTOpen Access, 
che rappresenta un altro grande e positivo fermento del mondo 
delTinformazione. La riproposizione dei contenuti del capitolo è 
praticamente integrale, tranne per quel che riguarda l'ultimo pa¬ 
ragrafo, quello dedicato agli editor per mashup. Popfly, l'editor 
di Microsoft recensito nella versione inglese del capitolo, è stato 
dismesso per confluire nel più ampio progetto del Microsoft Web 
Platform, un ambiente per lo sviluppo e Vhosting di applicazioni 
Web. Stessa sorte è toccata a Google Mashup Editor, a favore di 
Google App Engine, un ambienfe simile al concorrenfe. 

Yahoo! con il suo Pipes, il primo dei mashup editor a irrompere 
nella scena del Web e a registrare un successo che non declina ma 
anzi aumenta con il passare del tempo, sembra essere rimasto l'unico 
grande player interessato allo sviluppo di una piattaforma dedica- 

® http://books.infotoday.com/books/LibraryMashups.shtm. Al libro è dedicato 
anche unblog, a cura dell'editor Nicole Engard, http://mashups.web21earning.net/. 

^http: / /hdl.handle.net/10281/5117. 
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ta eminentemente all'utente medio di Internet per la creazione di 
mashup. A Pipes dedica un intero capitolo la curatrice del volume, 
Nicole Engard, pertanto vi rimando alla lettura del suo contributo 
per un approfondimento delle funzionalità di questo strumento. 

Concludo esprimendo la mia soddisfazione per la pubblicazione 
di un arficolo dedicalo ai mashup all'infemo del primo numero di 
una rivisfa di scienze dell'informazione che si prearmuncia seria e 
rigorosa ma anche aperfa e curiosa del nuovo. A Mauro Guerrini, 
che mi ha voluta testimone di questo battesimo, va la mia affettuosa 
gratitudine. 


Le API: il segreto dei mashup 

Secondo la definizione di ProgrammableWeb, un mashup compor¬ 
la la combinazione di dafi provenienfi da due o più fonfi web al 
fine di creare nuovi servizi e applicazioni.® Per creare un mashup è 
quindi essenziale poter ricavare informazioni strutturate dai siti web 
(o almeno poter convertire in informazione sfruffurafa il confenufo 
del silo una volfa esfraffo). 11 meccanismo più efficace per accedere 
a un servizio web è probabilmente la sua Application Programming 
Interface (API). Le API sono un insieme di funzioni e procedure per 
accedere a un servizio web: esse mosfrano la logica sulla quale il 
servizio è costruito, le sue risorse chiave e le funzioni passibili di 
essere invocale da programmi esfemi al silo. In alfre parole, le API 
consenfono a un programma di accedere a un web Service e di mani¬ 
polare i dafi esposfi, nello sfesso modo in cui l'inferfaccia web di un 
silo permette agli ufenfi di navigare al suo inferno ed esplorarne il 
confenufo. 


®La stesura di questo capitolo è debitrice a Karen Coyle e Raymond Yee per il loro 
generoso aiuto e supporto. 
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Ogni sito decide come esporre il suo contenuto verso l'esterno, 
perciò possono esservi grandi differenze fra fomifori di API - così 
come per lo stesso provider in relazione ai suoi differenti servizi. Na¬ 
turalmente, documentare pubblicamente le API e acconsentire a un 
loro libero e gratuito utilizzo, rende più semplice ai programmatori 
sfruttarle per i propri scopi. Ma perché un sito dovrebbe fornire API 
pubbliche ed esporre le proprie informazioni - quindi la fonie del 
proprio valore - gratuitamenfe online? hmanzifutto, perché permet- 
fere agli ufenfi di manipolare infensivamenfe i confenufi di un silo 
web o di invocare i suoi servizi da un client di un'applicazione ester¬ 
na, è un ottimo modo per testare l'applicazione: quando centinaia (o 
addirittura migliaia) di utenti cominciano a sviluppare servizi web 
sfruttando i contenuti di un sito, questo è di fatto sottoposto a un test 
su larga scala, e presumibilmente i bachi contenuti nell'applicazione 
verrarmo scoperti e sanati. 

Per ottenere informazioni sulle API è consigliabile consulfare la 
sezione "Sviluppo" (o "Developer", in inglese) del silo, all'inferno 
della mappa del sito, oppure le pagine di Help o ancora quelle delle 
FAQ; per converso, i siti che mettono a disposizione interfacce pub¬ 
bliche di accesso per gli utenti, dovrebbero assicurarsi che esse siano 
visibili sui portali che raccolgono informazioni sulle API (vedi più 
avanfi in quesfo capifolo). Un aspetto mollo imporfanfe da fenere 
in considerazione quando si adopera un'API è la licenza con cui è 
rilasciata o i cosiddetti "Terms of Service" (TOS), che rappresentano le 
condizioni stabilite dal provider del servizio. Possono infatti esservi 
limitazioni sul tipo di utilizzo che gli sviluppatori possono fare di 
un'API: nella maggior parie dei casi, le API pubbliche sono grafuife 
per finalità non commerciali, mentre per utilizzi di tipo commerciale 
il fornitore potrebbe richiedere il pagamento di un costo oppure 
bloccare del tutto l'accesso al servizio. Inoltre, esistono spesso li¬ 
mitazioni in ordine all'utilizzo di banda e al numero delle richieste 
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che vengono indirizzate verso il servizio. È anche utile notare che 
le API evolvono nel tempo e potrebbero cambiare: è pertanto ne¬ 
cessario verificare di tanto in tanto la documentazione fornita dal 
provider. Un altro problema cui prestare attenzione è il copyright 
sui contenuti utilizzati nel mashup: quanto viene pubblicato online 
potrebbe non essere legalmente riutilizzabile da altri oppure agli svi¬ 
luppatori potrebbe essere richiesto di implementare l'applicazione 
secondo specifici requisiti, per ottenere il permesso di ripubblicare o 
comunque riutilizzare le informazioni presentate online. Per tutte 
queste ragioni è necessario esaminare con accuratezza la licenza con 
la quale le informazioni sono state rilasciate e le condizioni alle quali 
possono essere utilizzate da terze parti. Laddove manchi una licenza 
specifica, è da presumere che valgano le consuete disposizioni di 
legge del Paese entro cui si sta operando. In aggiunta alla logica 
applicativa che permette agli sviluppatori di conoscere quali risorse 
siano rese disponibili e quali operazioni possano essere effettuate su 
esse, una caratteristica delle API sono i protocolli di comunicazione 
adoperati: come, da un punto di vista tonico, è possibile invocare 
l'interfaccia di programmazione perché lo scambio di informazioni 
abbia luogo? Quali sono i requisiti previsti per la costruzione delle 
richieste verso le API? Ma anche: in quali formati l'informazione 
verrà restituita al client che ha eseguito l'interrogazione? Quali ca¬ 
nali possono o devono essere usati perché lo scambio di contenuti 
sia rapido e sicuro? Per meglio comprendere e per cercare una rispo¬ 
sta a queste questioni, è arrivato il momento di dare un'occhiata al 
mondo dei web Service e alle sue molteplici funzionalità. 


Architettura dei Web Service 

Il W3C definisce un web Service come «a software System desi- 
gned to support interoperable machine-to-machine interaction over 
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a network».^ I web Service sono dunque una tecnologia che abilita lo 
scambio di informazioni e di comunicazioni tra differenti applicazio¬ 
ni. Comprendere come i web Service fimzionino è chiaramente un 
requisito fondamentale per il corretto uso delle API e la creazione di 
mashup efficaci. 

1 web Service sono basati su un modello concettuale che prevede 
un Service provider, cioè un'applicazione che pubblica le informazioni 
e/o che fornisce la possibilità di eseguire determinate operazioni, 
e un Service consumer, cioè un client che fa uso delle informazioni 
e/o dei servizi resi disponibili. Il Service consumer (per esempio il 
sito nel quale il mashup avviene) esegue una richiesta verso un 
Service provider (ovvero per esempio il sito che fornisce le API). Se la 
richiesta è effettuata nella maniera corretta, il Service provider invia 
una risposta formattata secondo le caratteristiche del servizio. 

Nella pratica, il protocollo di trasporto e il linguaggio più usati 
sono HTTP (HyperText Transfer Protocol) e XML (eXtensible Mar- 
kup Language). Se si lavora a un programma che deve acquisire 
informazioni, dati o servizi da im sito web attraverso un'API, è 
necessario conoscere i particolari requisiti tecnici di quel sito e co¬ 
struire la richiesta di conseguenza. Una volta formattata secondo 
i criteri richiesti dal sito web, la richiesta viene inviata attraverso 
uno dei metodi del protocollo HTTP: GET (quello che viene usato 
implicitamente nella normale navigazione in Internet), POST (adope¬ 
rato primariamente dal Service consumer per inviare informazioni 
verso il Service provider), PUT o DELETE (per particolari operazioni 
che devono essere effettuate sul server). Gli stili utilizzati nell'ar¬ 
chitettura dei zveb Service possono essere diversi in relazione alle 
tecnologie e ai protocolli impiegati: i più diffusi sono REpresen- 
tational State Transfer (REST) e SOAP (sigla che originariamente 
rappresentava Tacronrmo di 'Simple Object Access Protocol', ma che 

^http: //www. w3.org/TR/ ws-arch/#whatis. 
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ormai ha acquisito significato autonomo), che rappresentano le basi, 
rispettivamente, delle architetture resource-oriented e service-oriented. 

REST è il più semplice, e quindi il più utilizzato, protocollo nella 
creazione di mashup. Come vedremo nel paragrafo "Un esempio 
con Yahoo! Answers" (p. 147), REST consisfe di inferfacce basafe su 
un'archifeffura resource-orienfed, molto semplici da implemenfare. 
Concettualmente REST prevede im servizio che richiede informa¬ 
zioni o esegue delle operazioni da/su una specifica applicazione. 
La richiesta utilizza un URL contenente i parametri dell'API, ed è 
trasmessa usando uno dei metodi HTTP (per esempio GET). Da no¬ 
tare che l'architettura REST richiede che le operazioni siano invocate 
propriamente attraverso i metodi HTTP, e non all'interno delTURL 
inviato in Rete, come invece spesso accade, dal momento che TURE 
dovrebbe contenere soltanto la cosiddetta scoping information (ovvero 
le risorse richieste e non le operazioni da eseguire). Questo significa 
che, in imo stile pure REST, se si desidera semplicemente richiedere 
informazioni da un sito, occorre usare il metodo HTTP GET; se in¬ 
vece si richiede al Service provider di eseguire delle operazioni sulle 
sue risorse, allora la richiesta dovrebbe servirsi del metodo apposito 
- tipicamente POST, PUT, o DELETE.^ Sebbene la maggior parte 
dei Web Service dichiarino di essere RESTful, essi spesso espongono 
i propri dati in modalità ibride (per esempio inseriscono i metodi 
dell'API alTintemo delTURL invece di utilizzare correttamente il 
protocollo HTTP).® 

Quando una richiesta viene inviata attraverso la Rete, il Service 
provider fornisce una risposta contenente informazione formatfata 

^Le differenze tra lo stile REST puro e stili come il REST-RPC sono ben evidenziate 
nel libro RESTful iveb Services (Richardson e Ruby 2007) 

*Cfr. a questo proposito anche i post di Duncan Cragg: STREST (Service- 
Trampled REST) will break Web 2.0, http://duncan-cragg.org/blog/post/strest- 
service-trampled-rest-will-break-web-20/ e The REST dialogues http://duncan- 
cragg.org/blog / tag/ dialogue / 
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in un linguaggio di rappresentazione (spesso in XML, sebbene altri 
formati, come JavaScript Object Notation (JSON), siano sempre più 
utilizzati). Il Client può quindi usare la risposta come input per 
altre operazioni, oppure presentarla graficamente in una pagina 
Web. Come si può notare, la logica di richiesta-risposta dei zveb 
Service di tipo REST è la stessa che viene usata sul web quando un 
utente naviga sui vari siti online. Le uniche differenze sono che, 
da un lafo, le fransazioni sono attivale attraverso chiamale alle API 
invece che attraverso URL inviali in un browser, e, dall'alfro, che il 
formalo della risposfa è pensato per essere compreso (visualizzato, 
manipolato etc.) da un programma, invece che da un essere umano. 

SOAP è un altro stile che nel mondo dei web Service si è sviluppato 
accanto a REST; esso poggia su standard e protocolli intemazionali 
ed è stato adottato soprattutto nel mondo enterprise. SOAP usa 
HTTP come protocollo di trasporto per lo scambio di informazioni 
ma richiede che, sia la richiesfa inviala dal Service consumer sia 
la risposfa fomifa dal Service provider, siano "impacchettate" in un 
contenitore XML. Lo stesso provider descrive il web Service attraverso 
specifici XML schema, che vengono poi pubblicali online, in modo 
che le applicazioni che li utilizzeranno, possano conformarsi ad essi. 

La maggior parie dei siti 2.0 usano interfacce REST per le loro 
API. Ciò è comprensibile se si pensa che uno degli obiettivi del Web 
2.0 è abbassare quelle barriere fecniche che in passalo hanno impe- 
difo alTufenfe medio di parfecipare affivamenfe alla produzione di 
informazione online. E piuttosto semplice cosfruire una richiesfa 
attraverso Timpostazione dei parametri in un'URL e il suo invio 
verso un server, da un browser o un form web; ma è ancora più facile 
se TURE prende GET come mefodo: anche con scarse conoscenze 
di programmazione, oggi creare un mashup polente e funzionale è 
possibile grazie allo sfile REST. 

SOAP è senz'alfro più complesso da implemenfare e, secondo 
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quanto sostenuto dai fan di RESI (i cosiddetti RESTafarians), fallisce 
nel promuovere la facilità d'uso e l'efficacia implicite nel concetto di 
World Wide Web. È però importante comprendere come funziona 
l'architettura SOAP, sia perché molti siti usano solo SOAP, sia perché 
SOAP è più standardizzato ed elaborato di REST. Peraltro non è 
infrequente che tra i requisiti di un progetto di sviluppo business- 
oriented vi sia proprio la capacità di lavorare con SOAP. 


Dove trovare API online 

Quando ci si avvicina al mondo dei mashup per la prima volta, 
è molto utile poter avere accesso alle esperienze di altri utenti, così 
come conoscere i siti aperti al riutilizzo delle informazioni. Una 
risorsa di grande ufilifà da considerare per questo fipo di training è 
ProgrammableV\leb? Questo sito presenta attualmente il più ampio 
database di mashup; esso raccoglie anche news dal web, tendenze 
dal mondo dell'industria, informazioni tecniche, guide e riferimenti 
vari. Ogni mashup in ProgrammabìeWeb ha associata ima descrizione 
delle funzionalità che lo caratterizzano, insieme con l'elenco delle 
API usate, tag che ne descrivono i contenuti, informazioni sull'autore 
e link a mashup collegati. Inoltre, gli utenti di ProgrammabìeWeb 
possono votare i mashup proposti, aggiungerli ai propri preferiti e 
seguire attraverso i feed RSS altre applicazioni che fanno uso delle 
sfesse API. 

Come ci spiega Raymond Yee nel suo eccellente libro Pro Web 
2.0 mashup^^ (Yee 2008b), una maniera utile per sviluppare idee 
creative che potrarmo essere propedeutiche alla realizzazione di un 
mashup, è studiare le applicazioni già create da altri utenti e provare 
a rispondere a domande come le seguenti: 


®http://www.programmableweb.com 
i^http://blog.mashupguide.net 
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• Cosa viene combinato in questo mashup? 

• Perché proprio questi elementi vengono combinati? 

• Dove avviene il remix o la ricombinazione delle informazioni? 

• Come i vari elementi vengono combinati (e cioè, primariamen¬ 
te all'interno dell'interfaccia del mashup ma anche dietro le 
quinte di un'applicazione)? 

• Come è possibile estendere il mashup? (Yee 2008a) 

Queste domande e le loro risposte forniscono un'ufile griglia 
attraverso la quale analizzare i mashup presenti su ProgrammableWeb 
e aiutano ad approfondire le dinamiche e le problematiche coinvolte 
nella creazione di un mashup. 

È possibile imparare qualcosa del mashup anche studiando le 
informazioni convogliate dai componenti che abilitano il mashup, in 
particolare le API - le vere protagoniste dei mashup. Su Programma¬ 
bleWeb a ogni API è associato imo schema analitico che fornisce ima 
descrizione generale, i tag, le ulfime novità, un elenco di mashup 
che ne tarmo uso, i protocolli implementati {web Service di tipo REST 
e SOAP, con i relativi formati di output dei dati), le funzionalità (per 
esempio i diversi metodi da invocare), i protocolli di sicurezza adot¬ 
tati (autenticazione, SSL etc.), il supporto (offerto sia dal provider 
sia dalla comunità degli utenti), e infine i termini di utilizzo. Spesso 
sono presenti anche guide su come usare PAPI e i feedback di chi 
l'ha già testata. 

Le informazioni fornite da ProgrammableWeb rappresentano dun¬ 
que una insostituibile risorsa nel fornire una rappresentazione del¬ 
l'ampio panorama di siti che acconsentono all'utilizzo dei propri 
servizi e contenuti da parte di terzi. In più, i principianti apprezze¬ 
ranno la semplicità delle informazioni offerte dal sito e la possibilità 
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di effettuare ricerche nel database anche per librerie di codice e tool 
di sviluppo. 

ProgrammabìeWeb è una directory generalista e, tra le diverse mi¬ 
gliaia di mashup censiti, sono poche le applicazioni libmry-oriented. 
Grazie all'impegno del movimento della Library 2.0 e al rilascio 
di software di information management modulari e compatibili con 
gli standard più diffusi a livello internazionale, in tempi recenti i 
mashup e le API si sono conquistati una sempre crescente attenzione 
nel mondo dei professionisti dell'informazione. Il Library Software 
Manifesto^^ richiama l'importanza di API pubbliche per le bibliote¬ 
che che acquistano software di tipo ILS (Integrated Library System). 
E infatti solo grazie all'esistenza di interfacce pubbliche di accesso 
che tutti i dati - bibliografici e non - racchiusi nei database delle 
biblioteche possono essere utilizzati al di là degli usi previsti dai 
fornitori (naturalmente parliamo pur sempre di usi legali!). Sebbene 
le biblioteche, in quanto organizzazioni che lavorano primariamen¬ 
te (con) le informazioni, possano sembrare di diritto i protagonisti 
principali dell'universo di dati, mashup e web Service, in passato 
non si è registrata grande consapevolezza a riguardo, né intorno 
all'importanza di API aperte né relativamente al potenziale che esse 
hanno per le biblioteche e i loro progetti o obiettivi. Per esempio, 
non esistono molte API per i cataloghi Online e, al di là delle query 
previste dal protocollo Z39.50, è piuttosto difficile, se non impossibi¬ 
le, creare un mashup come il SOPAC^^ di John Blyberg, senza avere 
un'API che lo supporti. Spesso i bibliotecari non sanno se il software 
in uso nella propria biblioteca dispone di API e i vender non sempre 
forniscono spontaneamente questo tipo di informazioni. 

Questo scenario rende gli sforzi di social network come Mashed 
Library^^ ancora più importanti e meritevoli di attenzione. Il gruppo 


Il http : / / techessence.inf o / manifesto 
i^http://www.thesocialopac.net 
i^http://mashedlibrary.ning.com 
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che ha dato vita a questa rete, ha raccolto un elenco di API e di 
web Service library-oriented, poi incorporato in forma permanente 
all'interno del blog TechEssenced^ 

Tra le API elencate su TechEssence, diverse riguardano gli OPAC, 
così come i software per la gestione delle risorse digitali - e sono 
tutte rese disponibili da alcimi tra i maggiori player del mondo 
delTlnformation Technology, come OCLC, il sito di e-commerce 
Amazon, il fornitore di software per biblioteche Talis e il servizio di 
social bookmarking dedicato ai libri LibraryThingd® E da ricordare 
a questo proposito anche il /fSC Information Environment Service 
Registri) un catalogo di risorse elettroniche e repository digitali, 
che documenta web Service e API con i relativi requisiti, fornendo al 
contempo modalità di accesso e interrogazione attraverso i protocolli 
standard OAl-PMH, SRU, OpenURL e Z39.50. 

E insomma giunto il momento di stimolare e supportare le ini¬ 
ziative bottom-up delle biblioteche e del mondo LIS in generale, e di 
sfruttare (al) meglio la creatività dei bibliotecari per fare un uso degli 
applicativi più flessibile e al passo coi tempi. E tempo di sfruttare 
intensivamente gli Integrated Library System e indirizzarli verso un 
maggiore orientamento all'utente, condizionando positivamente le 
modalità con le quali le diverse fonti di contenuti digitali espongono 
i loro dati per rendere l'informazione disponibile ad essere usata da 
applicazioni di terze parti come i blog, i calendari Online o i feed 
RSS. In questo modo gli stessi utenti saranno messi nelle condizioni 
di creare applicazioni che né i vender né i bibliotecari avrebbero mai 
immaginato. 

Se, dopo aver letto questo capitolo, deciderete di "sporcarvi le 
mani" con lo sviluppo dei mashup, potete considerare sia Program- 


^^http: / /techessence.info/apis 
^®http: / / www.librarything.com 
i^http: / /iesr.ac.uk 
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mableWeb sia TechEssence come un buon punto di partenza per la 
scoperta della magia delle API. 


Mashup senza API 

Abbiamo descritto fin qui le API e i loro protocolli di comunica¬ 
zione, ma che accade se un sito non dispone di interfacce strutturate 
attraverso le quali servizi esterni possano recuperare le informazio¬ 
ni di cui hanno bisogno? Sebbene esisfano diversi siti che offrono 
inferfacce di programmazione, non fuffi le rendono pubblicamenfe 
disponibili per il riutilizzo di terze parti; in alcuni casi è possibile uti¬ 
lizzarle solo a pagamento, mentre in altri le aziende tengono le API 
segrete poiché esse vengono considerate strategiche per il successo 
commerciale di un prodotto o di un servizio. Parimenti, esistono 
siti web che non offrono nessun tipo di interfaccia con cui interagire. 
In questi casi è più difficile ufilizzare i dafi, ciò nonosfanfe possono 
esservi comunque buone chance di creare un mashup. 

Raymond Yee nel suo libro invila a sfudiare irmanzifuffo le spe¬ 
cifiche modalifà di cosfruzione degli URL {URL languagé) usale dal 
silo di inferesse. Quesfo è ufile quando anche un'API è disponibile 
ma diviene cruciale nei casi in cui non esistono API da utilizzare ed è 
necessario scoprire autonomamente l'architettura delle informazioni 
adottala dal silo. Il modo in cui gli indirizzi web sono cosfruifi può 
aiufare a capire se e come l'informazione è sfruffurafa in risorse 
idenfificabili da URL, oppure cafegorizzafa, faggafa o comunque 
organizzala in modo fale che un programma sia in grado di operare 
con essa. 

Una fonie affidabile di dafi formattali in maniera appropriala e 
che consenfe il loro ri-ufilizzo all'infemo di web Service è il feed di 
un silo web. Ifeed non sono alfro che piccoli pezzi di informazione 
rappresenfafi in XML o in uno dei suoi dialetti (come RSS o ATOM), 
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normalmente usati dai siti per disseminare gli aggiornamenti dei 
propri contenuti e letti dai navigatori per il mezzo di aggregatori o 
feed reader. in effetti ìfeed possono essere visti come un semplice weh 
Service RESTful, dal momento che una risposta formattata in XML è 
invocata da una richiesta formulata attraverso un URL trasmesso su 
HTTR Utilizzando il file che risiede sotto il tipico pulsante arancione 
che indica la presenza di un feed, lo sviluppatore può analizzare le 
informazioni e usarle come inpuf per un'alfra applicazione o rende- 
rizzarle direttamente in una pagina web. La presenza di funzionalità 
di import/export di contenuti o l'utilizo di tecnologie di sviluppo 
web come AJAX (linguaggio basato su JavaScript e XML usato per 
la creazione di applicazioni web dinamiche), sono altri indizi che il 
sito dispone di dati processabili da un programma esterno. Se un 
sito non fornisce nè un chiaro URL language nè feed o alfre modalifà 
di accedere ai suoi dafi, allora occorre affidarsi semplicemenfe alla 
sua inferfaccia web, usando la fecnica noia come screen scraping. 
Attraverso quesfo meccanismo, le informazioni concepife esclusi- 
vamenfe per essere visualizzafe e usafe da esseri umani (gli ufenfi 
del silo), vengono esfraffe dalle pagine web e inviale come inpuf 
a un programma. L'applicazione di fipo screen scraper, quindi, agi¬ 
sce sul livello più superficiale delle pagine web, ovvero il livello di 
presenfazione dei confenufi, e usa i tag HTML come agganci per 
identificare le risorse informafive desiderale. 

Nafuralmenfe, queste tecniche di hacking producono risultati 
spesso instabili e inaffidabili: se un sito non mette a disposizione 
un'API, possono esservi solide ragioni - incluse quelle legali - perchè 
esso non renda disponibili i propri dati per l'utilizzo da parte di ap¬ 
plicazioni esterne. E quindi necessario analizzare accuratamente se 
lo screen scraping può essere usato in una particolare situazione, an¬ 
che se esso rappresenta l'unica opportunità di ottenere informazioni 
da riufilizzare. 
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Un esempio con Yahoo! Answers 

Passiamo adesso dalla teoria alla pratica e vediamo come un 
vero zveb Service è in grado di effettuare richieste da una fonte Online 
e di processare i dati che ottiene in risposta per renderli utilizzabili 
all'interno di un mashup. Dal momento che un mashup combina 
dati provenienti da due o più fonti, per ciascuna di esse occorrerà 
comprendere le peculiari modalità di input e output dei contenuti e 
delle informazioni, come vedremo in questo paragrafo con Yahoo! 
Answers. Esistono molfi sifi che rendono le proprie API disponibili 
per gli utenti: motori di ricerca come Google, che offre l'opportunità 
di interrogare direttamente il suo indice; siti di media sharing come 
Flickr^^ e YouTube,^® dai quali è possibile ottenere filmati e foto; ag- 
gregatori come Technorati^® e Feedreader,^® che foniscono contenuti 
user-generated e feed, e molti altri. Yahoo! Stesso offre una grande 
varietà di API e web Service che interagiscono con il suo motore di 
ricerca con altri servizi Online come le mappe, la musica, l'informa¬ 
zione finanziaria, il social bookmarking e così via. Nello Yahoo! 
Developer Network (YDN)^^ è possibile trovare tutte le informa¬ 
zioni necessarie sulle interfacce delle applicazioni disponibili e su 
altre tecnologie collegate, insieme con guide e video-tutorial, librerie 
per il web design, una galleria di mashup, report sulle iniziative di 
hacking sponsorizzate e infine il supporto sia dell'azienda sia della 
community degli sviluppatori. All'interno di questa molteplicità 
di servizi, abbiamo scelto di occuparci in questo capitolo di Yahoo! 
Answers.^^ 


i^http://www.flickr.com 
i^http://www.youtube.com 
i®http://www.technorati.com 
^^http://www.feedreader.com 
^'http://developer.yahoo.com 
^^http://answers.yahoo.com 
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Yahoo! Answers è una «online community where anyone can 
ask and answer questions on any topic. Yahoo! Answers connects 
people to thè information they're seeking with those who know 
it».^^ Consultando la sezione YDN di Answers^^ scopriamo che 
sono disponibili API per l'accesso e il riutilizzo di domande e ri¬ 
sposte pubblicate dagli utenh su Yahoo! Answers. Le API usano 
un'interfaccia di tipo REST: per quanto detto sopra, se desideriamo 
interrogare questa interfaccia abbiamo bisogno di: 

1. cosfruire un'URL secondo i paramefri specificafi dall'API, 

2. inviarlo ufilizzando uno dei melodi HTTP richiesfi. 

Se si vogliono usare le API di Yahoo!, occorre richiedere innanzi- 
fuffo un Applicafion ID.^® Quesfa procedura è spesso richiesfa dai 
siti che mettono a disposizione le proprie API, perchè in questo mo¬ 
do il Service provider può tracciare il numero e il tipo di richieste e la 
banda di cui ogni applicazione fa uso, in aggiunta alle caratteristiche 
del Client che richiede i contenuti. 

Ci sono quattro tipi di query disponibili per l'interazione: question- 
Search, getByCategory, getQuestion e getByUser. Le query restituiscono, 
rispettivamnte: le domande che trattano dell'argomento scelto nel¬ 
la query, le domande archiviate sotto una certa categoria; dettagli 
di tutte le risposte fomite a una domanda; le domande postate su 
Yahoo! Answers da uno specifico utente. La pagina dedicata alle 
API ha anche im form web attraverso il quale è possibile testare le 
query e verificare le risposfe fornife dal servizio. L'unico metodo 
HTTP disponibile per questa API è GET; dunque è possibile solo 
leggere le informazioni dal silo, non modificarle, caricarne di nuove 
o eliminare dafi sul server. 

^^http://help.yahoo.com/l/us/yahoo/answers/o ver view/overview- 
55778.html 

^^http: / /developer.yahoo.com/answers 
^®http: / /developer.yahoo.com/wsregapp 
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La prima query, questionSearch, "finds open, resolved, or up-for- 
vote questions that include your search terms". Per accedere alle 
informazioni desiderate, è necessario costruire una richiesta che 
recuperi le domande pubblicate su Answers, utilizzando i parametri 
forniti dall'APl. 11 target URL a cui la richiesta va indirizzata è: 

http://answers.yahooapis.com/AnswersService/Vl/questionSearch 

dove http://answers.yahooapis.com/ è Vhostname dell'API e Answers- 
Service il nome del servizio. L'acronimo VI, posizionato di seguito, si 
riferisce al numero di versione dell'API e questionSearch rappresenta 
il tipo di query che abbiamo scelto. Alcuni tra gli argomenti che 
possono essere utilizzati per questo tipo di richieste sono: 

• query: ricerca i termini (obbligatorio) 

• category_id: ricerca solo in specifiche categorie attraverso gli 
ID corrispondenti (gli ID possono essere individuati nell'URL 
navigando tra le categorie di Yahoo! Answers) 

• region: filtro basato sulla nazione (per esempio, us: United 
States; uk: United Kingdom;it: Italy e così via) 

• sort: imposta l'ordinamento nel set dei risultati per 

- relevance: rilevanza (default) 

- date_desc: data discendente (le domande più recenti per 
prime) 

- date_asc: data ascendente (le domande più vecchie per 
prime) (si può omettere per l'opzione di default: relevan¬ 
ce) 

• appid: Vapplication ID (obbligatorio) 
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• output: definisce l'output della cali. Valori accettati sono - 
xml, json, php e rss (si può omettere per l'opzione di default: 
"xml")26 

Per esempio, per ottenere tutte le domande chieste da utenti 
statunitensi riguardanti l'energia solare (solar energy) all'mterno 
della sotto-categoria Green Living, e ottenere i risultati ordinati per 
data con i più recenti in cima, occorrerebbe costruire il seguente 
URL: 


GET http://answers.yahooapis.com/AnswersService/Vl/ciuestionSear 
ch?appid=MyYahooAppld&query=solar%20energy&category_id=21 
15500307&region=us&sort=date_desc^^ 


(da notare che la stringa MyYahooAppld va sostituita con il pro¬ 
prio identificativo, e che gli argomenti e i loro valori varmo IIRL- 
encoded).^^ 11 numero 2115500307 in category_id è l'identificativo 
della categoria Environment/Green Living category, come mostrato 
nell'URL della corrispondente pagina web di Yahoo! Answers. Di 
default il massimo numero di risultati è dieci e il formato di pre¬ 
sentazione dei risultati è l'XML. Dal momento che non abbiamo 
specificato nessuno di questi due parametri, il servizio di Yahoo! uti¬ 
lizzerà le impostazioni pre-impostate. È possibile testare questo URL 

^*Gli argomenti e le loro spiegazioni sono riportati dalla pagina questionSearch 
{http://developer.yahoo.com/answers/Vl/questionSearch.html) 

^^Vedi Yahoo! Developer Network per ottenere informazioni su come costruire 
URL di tipo REST (http://developer.yahoo.com/search/rest.html) 

^®La URL encoding (o Percent encoding) è una tecnica usata per convertire i caratteri 
speciali presenti in un URL, in un formato valido. Per esempio, lo spazio tra le parole 
in composti come energia solare (solar energy), viene codificato nell'URL come %20. 
Per maggiori informazioni si veda la pagina dedicata all'argomento su Wikipedia 
(http://en.wikipedia.org/wiki/Percent-encoding) e un elenco di caratteri codificati 
{www.w3schools.com/TAGS/ref_urlencode.asp) 
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incollandolo nella barra degli indirizzi del browser:^® il risultato sarà 
una risposta formattata in XML contenente le informazioni richieste 
più un insieme di valori ulteriori come Vid e il nick nume dell'utente 
che ha posto la domanda, il numero di risposte fomite per ogni do¬ 
manda e - se esiste - la risposta scelta come migliore. Il codice XML 
può essere analizzato e inviato come input a una applicazione di 
terze parti oppure trasformato in una pagina HTML per mostrare i 
risultati nel proprio stile grafico preferito. Per esempio, un consorzio 
di biblioteche su scala nazionale o regionale, potrebbe cooperare nei 
servizi di reference sviluppando un mashup che raccolga all'interno 
di im'unica interfaccia domande su un certo argomento, provenienti 
sia dagli utenti del servizio di reference online delle biblioteche sia 
dagli utenti di Yahoo! Answers. 

È anche possibile ottenere im feed in risposta scegliendo RSS 
come formato di output {&output=rss). In questo caso l'URL che 
risulta dalla chiamata alla API è l'indirizzo di un feed RSS che può 
essere usafo da un feedreader per offenere nofifiche ogni qual volfa 
vengono pubblicale su Answers nuove domande che rispondono ai 
requisiti pre-impostafi. 

Il formato JSON restituisce un JavaScript serializzato, un formato 
più lineare dell'XML che è fornito di default. JSON può essere usato 
in combinazione con la funzione di callback resa disponibile tra i 
parametri dell'API per risolvere problematiche di sicurezza come la 
Same Origin Policy, che si presentano quando le applicazioni per il 
mashup utilizzano linguaggi di programmazione client-side come 

possibile invocare un'API da un'applicazione scritta in un linguaggio server- 
side come Perl e PHP orppure da un client Ajax. Oppure si possono provare le fun¬ 
zionalità dell'API inviando la richiesta attraverso un programma a linea di comando 
come cURL o attraverso l'estensione per Firefox Poster. Yahoo! Developer Network 
offre rm Software Development Kit (SDK) (http:/ / developer.yahoo.com/ download/) 
con librerie di codice disponibili per utilizzo pubblico, per implementare web Service 
in diversi linguaggi di programmazione 
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JavaScript. Bisogna poi tener presente che questo web Service limita 
le query per indirizzo IP a 5.000 al giorno e che richiede obbligato¬ 
riamente la sottoscrizione degli Yahoo! API Terms ofUse^^ e Terms of 
Service^^ Infine, i siti web e le applicazioni che usano questo servizio 
di Yahoo! devono mostrare in chiaro la dicitura "Powered by Yahoo! 
Answers". 


Editor per Mashup 

Un vantaggio significativo dell'attuale livello di attenzione in¬ 
torno ai mashup, è il fatto che ci sono sempre più tool e servizi che 
rendono la creazione di un mashup un processo veramente semplice, 
anche per l'utente medio di Internet. Alcimi di questi eliminano 
interamente il ricorso alla programmazione, nascondendo i dettagli 
tecnici e presentando interfacce semplificafe. Alcune grandi compa¬ 
gnie harmo cominciato a lavorare agli editor per mashup, ovvero ad 
applicazioni che permettono di ricombinare le informazioni attra¬ 
verso semplici comandi all'intemo di un'interfaccia grafica. Come 
spiega Nicole Engard nel capitolo del libro "Library Mashups: Explo- 
ring New Ways to Deliver Library Data", Yahoo! con il suo Pipes^^ 
ha rivoluzionato il panorama dei mashup editor: con la semplice 
giustapposizione di box contenenti gli indirizzi Web dei servizi che 
si intende utilizzare, Pipes consente di combinare contenuti testuali 
e multimediali provenienti da fonti diverse, dando luogo a un feed 
RSS. 

Tra gli altri editor con interfaccia grafica, vanno ricordati Mashup 
Maker^^ e Dapper^^, così come tool più business-oriented come JackBe 

^‘'http://mfo.yahoo.com/legal/us/yahoo/api/api-2140.html 
^ihttp://mfo.yahoo.com/legal/us/yahoo/utos/utos-173.html 
^^http: / /pipes.yahoo.com 
^3http://mashmaker.intel.com/web/mdex.php 
^^http: / / www.dapper.net 


152 



JLIS.it. Voi. 1 , n. 1 (Giugno/June 2010) 


Presto Platform^® e Serena^^. 

In genere, però, a coloro i quali muovono i primi passi nel mondo 
del mashup e hanno limitate competenze informatiche, è consigliato 
cominciare con un editor "visuale" e in questo caso Yahoo! Pipes, 
con la sua copiosa documentazione, gli esempi, i numerosi moduli 
già creati a disposizione e, last hut not least, un'ampia community a 
corredo, è senz'altro il candidato ideale. 
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